inscatolati - Get out of the box! :)

Symptoms: customers accessing their own mailboxes report Outlook crashing or the connection being dropped, with a message similar to "Your server has unexpectedly terminated the connection...". You look into the user mailbox, and there doesn't seem to be anything strange. If you look carefully, you should see one or two really small mails.

It seems like Norton Antivirus causes Outlook to crash or the connection being dropped when a user receives a mail without body and no \n after the headers.

The problem has been reported to the CERT as a potential DoS, and Norton seems well aware of that problem. However, no fix is provided.

Two possible solutions:

• configure your mail server to always add a \n after the headers of any received email, even when there is no body.

• disable some Norton Antivirus options. Take a look at this issue on the Symantec Support site and to those instructions for more useful data. The links: Microsoft support and C4 Net support might also contain useful info.

If you are seeing this error when trying to access a web TLA archive, it probably means that the archive was created without the '-l' options to the make-archive command, or, for some reasons, no .listing files were created.

In this case, the only way to fix the archive is to ask the archive administrator, or someone with write permissions on the archive, to create the 'http-blows' file and to run a 'tla archive-fixup' command.

For more details, please take a look at http://notes.inscatolati.net/[en]/software[en]/tla[en]/index.html#7

If you use LVM over RAID 5 on a 2.4 kernels, you might easily have errors like:

raid5: switching cache buffer size, 4096 --> 1024 raid5: switching cache buffer size, 1024 --> 4096 [...]

These messages are repeated almost everytime there is a disk access, flooding both your console, your logs, and degrading performance.

A quick and easy hack would be to create the filesystem with a block size of 4096. In the case of ext3, something like:

# mkfs.ext2 -b 4096 /dev/mapper/vg00-lv00

With this option, you will see your logs being flooded only when you are using low level tools, like 'vgs', 'lvs', 'tune2fs', and so on...

With other file systems, there are equivalent options to set the block size to 4096 bytes...

The whole message looks something like:

Setting up LVM Volume Groups... Reading all physical volumes. This may take a while...

followed by lot of kernel messages.

Well, that's the problem: lvscan, to find all the phyisical volumes, will just scan the first few sectors of every device on the system.

If you happen to have something particularly slow, lot of devices, or ... you are an aficionado of devfs (which will probe modules as pvscan tries to find those volumes), you will want to change /etc/lvm.conf.

Just add something like:

filter = [ "a|/dev/md*|", "a|/dev/sd*|" ]

in that file, to tell pvscan to search only in /dev/md* and /dev/sd*